home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9703 / 000073_owner-urn-ietf _Fri Mar 28 06:32:19 1997.msg < prev    next >
Internet Message Format  |  1997-04-01  |  4KB
  1. Received: (from daemon@localhost)
  2.     by services.bunyip.com (8.8.5/8.8.5) id GAA15818
  3.     for urn-ietf-out; Fri, 28 Mar 1997 06:32:19 -0500 (EST)
  4. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
  5.     by services.bunyip.com (8.8.5/8.8.5) with SMTP id GAA15813
  6.     for <urn-ietf@services.bunyip.com>; Fri, 28 Mar 1997 06:32:15 -0500 (EST)
  7. Received: from nix.swip.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  8.         id AA14661  (mail destined for urn-ietf@services.bunyip.com); Fri, 28 Mar 97 06:32:13 -0500
  9. Received: from localhost (paf@localhost) 
  10.           by nix.swip.net (8.8.2/8.8.2) with SMTP 
  11.           id MAA16340; 
  12.           Fri, 28 Mar 1997 12:32:09 +0100 (MET)
  13. Date: Fri, 28 Mar 1997 12:32:09 +0100 (MET)
  14. From: Patrik Faltstrom <paf@swip.net>
  15. To: Dan Connolly <connolly@w3.org>
  16. Cc: urn-ietf@bunyip.com, Cecilia Preston <cecilia@well.com>
  17. Subject: Re: [URN] draft Bibliographic Identifiers to URNs
  18. In-Reply-To: <333B7A8A.38671A84@w3.org>
  19. Message-Id: <Pine.SUN.3.95.970328122020.15812F-100000@nix.swip.net>
  20. Mime-Version: 1.0
  21. Content-Type: TEXT/PLAIN; charset=US-ASCII
  22. Sender: owner-urn-ietf@Bunyip.Com
  23. Precedence: bulk
  24. Reply-To: Patrik Faltstrom <paf@swip.net>
  25. Errors-To: owner-urn-ietf@Bunyip.Com
  26.  
  27. On Fri, 28 Mar 1997, Dan Connolly wrote:
  28.  
  29. > Cecilia Preston wrote:
  30. >
  31. > > Example: URN:ISBN:0-395-36341-1
  32. > 
  33. > Huh? Why the URN:? Why not just ISBN:0-395-36341-1?
  34. > 
  35. > Since ISBNs are hierarchical, ISBN:/0/395/36341/1 would
  36. > make more sense.
  37.  
  38. We have been through this a bizillion times, and at the last IETF we
  39. concluded that the URN: _must_ be there because of the functional
  40. differences on what a URL and a URN is. Several different argumentation
  41. rounds have been going on weather it is possible to _technically_ use them
  42. interchangeable, but the conclusion in the URN working group is that the
  43. URN: should be there.
  44.  
  45. We can _NOT_ start this debate again. Sorry if I sound harch Dan, but you
  46. have to look in the email archives for argumentation, and see the minutes
  47. from the San Jose IETF.
  48.  
  49. > I guess I've got problems with the
  50. > draft-ietf-urn-nid-req. Basically: why is it a different
  51. > document from the URL process document? But that's fodder
  52. > for another message.
  53.  
  54. It is different because we have different requirements on the NID than a
  55. URL scheme. Maybe we can use the same process, but different requirements?
  56.  
  57. You also say
  58.  
  59. >> A namespace is definitely not the same thing as a URL scheme. Two
  60. >> different things, but the _process_ can be similar, just like the
  61. >> processes defined for MIME-types.
  62. >
  63. > Hmm... argument by assertion. I can play that game too:
  64. > A namespace definitely IS the same thing as a URL scheme.
  65. >
  66. > I don't have any logical argument, but I can cite the
  67. > intent of the designer of URLs:
  68.  
  69. This was something I argued with Tim about 1992 already, and I have been
  70. arguing about this since...as the others being in Stockholm/Helsinki when
  71. this was discussed: Peter Deutsch, Chris Weider, Mark McCahill, Alan 
  72. Emtage, Tim, Joyce Reynolds, Anders Gillner et.al. We others basically
  73. wanted to have some things fixed in HTTP/HTML _BEFORE_ it was sent to
  74. "the masses":
  75.  
  76.   + The ability of _not_ having stateless connections on top of TCP
  77.     between a client and a server.
  78.   + The ability of formatting www-pages in a better way (look at TeX)
  79.     because people want tables, windows (what is now frames) and the
  80.     ability of changing fonts, sizes, layout commands like putting things
  81.     side by side.
  82.   + The problem that you don't know what you are fetching in HTTP until
  83.     the HTML header arrives, i.e. you have to start fetching before you
  84.     see what you get. Look at ol' Gopher+ and the attributes in the
  85.     links.....
  86.  
  87. I see that the same things are still discussed and many are fixed in new
  88. versions of HTML/HTTP...
  89.  
  90. Anyway, I just wanted to point out that these things that start to get
  91. discussed over and over again has been discussed forever...and they will
  92. probably always be discussed forever.
  93.  
  94. Can anyone write an FAQ? Until we have one, we can not blame _anyone_ for
  95. asking these questions over and over again.
  96.  
  97. Am I getting old?
  98.  
  99.    Patrik
  100.